Systems, methods, and language for SCA CORBA descriptor files

ABSTRACT

A preparser tool is provided for converting Software Communications Architecture (SCA) Extensible Markup Language (XML) files into Common Object Request Broker Architecture (CORBA) structures usable by an SCA Core Framework (CF) and comprises a CF_PreParsers interface definition language (IDL) and a first preparser. The CF_IDL is configured to be in operable communication with an XML parser and with at least a first type of preparser. The first type of preparser is in operable communication with the CF_PreParsers IDL, is associated with a first type of descriptor for the CF, and is configured to call the XML parser to request parsing of a first set of first XML files, convert the first parsed set of first XML files into a first CORBA structure type, encode the first CORBA structure type into a first CORBA Common Data Representation (CDR) file; and write the first CORBA CDR file as a first octet sequence.

FIELD OF THE INVENTION

Embodiments of the invention generally relate to software communicationarchitectures for radios and other applications. More particularly, theinvention relates to systems and methods that improve operation of suchsoftware communication architectures by removing the XML parser from theenvironment in which the software architecture is implemented.

COMPUTER PROGRAM LISTING APPENDIX

This application includes herewith a transmittal under 37 C.F.R §1.52(e)of a Computer Program Listing Appendix on Compact Disk (CD), where thetransmittal comprises duplicate compact discs (CDs), totaling two (2)CDs, respectively labeled “Copy 1” and “Copy 2”. Each disk contains thesame files. The discs are IBM-PC machine formatted and MICROSOFT WINDOWSOperating System compatible, and include identical copies of thefollowing list of eight (8) files, where each file has been saved as adocument viewable using MICROSOFT WORD. All of the materials on thecompact disk, including the computer program listings contained in thefollowing eight (8) files, are incorporated herein by reference in theirentirety. The eight files include:

-   CF_Parsers_IDL.doc (62 Kbytes) (Apr. 21, 2011);-   CF_PreParsers_IDL.doc (128 Kbytes) (Apr. 21, 2011);-   DeviceConfigurationParser_IDL.doc (26 Kbytes) (Apr. 21, 2011);-   DCD_IDL.doc (26 Kbytes) (Apr. 21, 2011);-   DomainManagerConfigurationParser_IDL.doc (27 Kbytes) (Apr. 21,    2011);-   DMD_IDL.doc (26 Kbytes) (Apr. 21, 2011);-   SoftwareAssemblyParser_IDL.doc (26 Kbytes) (Apr. 21, 2011); and-   SAD_IDL.doc (28 Kbytes).

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection (including, but not limited tothe material contained in the Computer Program Appendix). The copyrightowner has no objection to the facsimile reproduction by anyone of thepatent document or the patent disclosure, as it appears in the Patentand Trademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

BACKGROUND OF THE INVENTION

A Software Defined Radio (SDR) is a radio whose function is defined notby its underlying hardware, but instead by its software, such that itsoutput signal is determined by software. SDR systems are thusreconfigurable, within the limits of the actual underlying hardwarecapabilities, by loading new software as required by a user. FIG. 1 is ablock diagram of an exemplary prior art SDR system 20. The exemplary SDRsystem 20 includes a means for receiving an analog or digital radiowaveform at a transmission frequency (e.g., an antenna 28 and associatedhardware) along with an SDR hardware component 26, an SDR softwarecomponent 24, and an SDR client 22.

The SDR hardware component 26 includes a radio receiver and/or radiotransmitter (which is shown for illustrative purposes only in FIG. 1 asa radio transceiver 34), as well as an analog-to-digital (A/D) converter(ADC) 30 for conversion of the radio waveform 48 (also referred to asanalog baseband input) is required) to a digital baseband input signal44 to the SDR software c component 24, and a digital to analog (D/A)converter (DAC) 32, for D/A conversion of the digital baseband output 46from the SDR software component 24. The radio transceiver 34 is acomponent well understood by those of skill in the art and includes, forexample, a radio frequency (RF) subsystem 38 and an intermediatefrequency (IF) subsystem 36. In the receiving mode, signals received bythe antenna 28 are processed by the RF subsystem 38 and IF subsystem 36:for example, the signals received at antenna 28 can be processed in atuner (to select the desired signal, such as by filtering), a detector(to extract audio signal from the signal selected by the tuner),downconverted to the desired baseband frequency, and then sent to theADC 30 to be converted from an analog baseband signal 48 to a digitalbaseband data signal 44.

In the transmit mode, the digital baseband output signal 46 from the SDRsoftware component 24 is sent to DAC 32 for conversion to an analogbaseband output signal 49, the analog baseband output signal 49 is sentthe IF subsystem 36 and RF subsystem 38 of the radio transceiver 34 tothe basic radio transceiver 26 for further processing, which may includeupconverting the analog baseband output signal 49 to the appropriatetransmission frequency, amplification, and filtering, then sent toantenna 28 for transmission.

The SDR software component 24 runs on a host, which can be ageneral-purpose computer system (such as described further herein inconnection with FIG. 2), or hardware that has been configured bysoftware, such as a field-programmable gate array (FPGA), embeddedcomputing device, multiprocessor embedded systems, any equivalentcomputing/processing circuit. A waveform can consist of a set of SDRsoftware components executing on general purpose processors, FPGA's,digital signal processors, etc. The host is able to handle aconsiderable amount of the signal processing previously done byconventional radio hardware components such as mixers, filters,amplifiers, modulators/demodulators, detectors, etc. Thus, the SDRsystem 20 provides a radio that can receive and transmit widelydifferent radio protocols (sometimes referred to as waveforms) basedsolely on the software used.

The SDR software component 24 is in operable communication with the SDRhardware component 26 via one or more data channels. For example, inFIG. 1, the data channels include a first data channel 44 that permitsreception of digital baseband input data from the ADC 30 of the SDRhardware component 26, a second data channel 46 that permitstransmission of digital baseband output data from the SDR softwarecomponent 24 to the SDR hardware component 26, and a control datachannel 47 that permits transmission of control data from the SDRsoftware component 24 to the SDR hardware component 26. The SDR softwarecomponent 24 receives client input data 40 from an SDR client 22 andsends client output data 42 to the SDR client 22.

The digital baseband output 46 typically results from the SDR softwarecomponent 24 performing a series of digital signal processing (DSP)functions necessary to prepare the client input data 40 from the SDRclient 22 for transmission by the SDR hardware component 26. Thesefunctions may include: source encoding, encryption, error-correctioncoding, and baseband modulation, as well as the aforementioned functionsperformed by hardware components such as mixers, filters, amplifiers,modulators/demodulators, detectors, etc.

The SDR software component 24 of FIG. 1, as noted above, as well as theSDR client 22, each can be implemented using a known computing systemsuch as a general purpose computer. FIG. 2 provides an illustrationgiving an overview of an exemplary computing system 50 usable with atleast some embodiments of the invention. Note that systems and methodsin accordance with the invention can be implemented using any type ofcomputer system running any one or more types of operating systems.Exemplary types of computer systems on which at least some embodimentsof the invention can be embodied include any system or device having aprocessor (or equivalent processing functionality) installed orembedded, including but not limited to a desktop computer, personalcomputer (PC), laptop computer, notebook computer, tablet computer,handheld computer, netbook, personal digital device (including but notlimited to personal digital assistant (PDA), mobile communicationsdevice (including but not limited to radio, conventional telephone,mobile/cellular telephone, smart phone, music playing device, electronicreading device) server, workstation, and interconnected group ofcomputers, as well as any other type of device having a microprocessorinstalled or embedded thereto, such as a field-programmable gate array(FPGA).

Referring now to FIG. 2, the computer system 50 includes a centralprocessor 1, associated memory 2 for storing programs and/or data, aninput/output controller 3, a disk controller 4, a network interface 5, adisplay device 7, one or more input devices 8, a fixed or hard diskdrive unit 9, a removal storage device/drive (optional) 13, optionally abackup storage device (e.g., a tape drive unit) (not shown) and a databus 6 coupling these components to allow communication therebetween.

The central processor 1 can be any type of microprocessor, such as aPENTIUM-family processor, made by Intel of Santa Clara, Calif. Thedisplay device 7 can be any type of display, such as a liquid crystaldisplay (LCD), plasma display, cathode ray tube display (CRT), lightemitting diode (LED), and the like, capable of displaying, in whole orin part, any desired information. The input device 8 can be any type ofdevice capable of providing the desired inputs, such as keyboards,numeric keypads, touch screens, pointing devices, switches, styluses,and light pens. The network interface 5 can be any type of a device,card, adapter, or connector that provides the computer system 50 withnetwork access to a computer or other device, such as a printer. Forexample, the network interface 5 can enables the computer system 50 toconnect to a computer network such as the Internet. Other computeraccessories well-known to those of skill in the art (e.g., microphones,cameras, speakers, biometric access-control devices such as fingerprintscanners, etc.), although not illustrated in the block diagram of FIG.2, can of course be included as part of the computer system 50.

SDR is advantageous, flexible, efficient, and economical for users,because the SDR can evolve to meet changing or new standards byreplacing software. In addition, use of SDR improves interoperability,because groups that each use SDR devices based on incompatible standardscan communicate with each other by loading each group's SDR device withsoftware that enables the two incompatible SDRs to communicate. SDR canbe advantageous in military applications, and the United StatesDepartment of Defense (DoD), through its, Joint Tactical Radio System(JTRS) Joint Program Execute Office (JPEO) in San Diego, Calif., nowrequires that all radios delivered to any of the armed forces adhere toa so-called “Software Communications Architecture” (SCA) specificationfor SDR, which specification is hereby incorporated by reference in itsentirety. Goals of the SCA standard include allowing all militarybranches to cooperate, reduce cost, increase interoperability, andprovide the ability to upgrade and/or extend such SDRs developed inaccordance with the SCA, from either or both of the software andhardware sides of the radio.

Several versions of the SCA specification have been developed. At thetime of this writing the latest specification prepared by the STRS JPEOis SCA 2.2.2 dated 15 May 2006, the entirely of which is herebyincorporated by reference, including all of its appendices, includingAppendix A (Glossary), Appendix B (Application Environment Profile(AEP)), Appendix C (Interface Definition Language (IDL)), Appendix D(Domain Profile), Appendix D (Common Properties) Attachment, Appendix D(Common Properties) Readme Attachment. In addition, as of this writing,a new proposed SCA specification, tentatively referred to as SCA NEXT,was introduced in December 2010. Both SCA 2.2.2 and SCA NEXT, includingall Appendices, are hereby incorporated by reference.

FIG. 3A is an illustrative block diagram of a prior art SCA architecture10 (developed in accordance with SCA 2.2), which architectureillustrates the general structure of its software architecture. FIG. 3Bis a prior art block diagram 11 showing the core framework (CF) layer 16interface definition language (IDL) relationships of the prior artarchitecture of FIG. 3A. The prior art systems of FIGS. 3A and 3B aredescribed briefly below and in greater detail in the SCA 2.2.2specification itself. The elements in and operation of FIGS. 3A and 3B,along with a detailed description of a related prior art embeddeddistributed XML parser, are further described in commonly-assigned U.S.Pat. No. 7,367,020 (“the '020 patent”), entitled “Executable RadioSoftware System and Method,” which is herein incorporated by referencein its entirety.

As illustrated in FIGS. 3A and 3B, software used in at least some SCAarchitectures/systems 10 is organized into three layers: a processorenvironment layer (including operating system 12), a middleware layer14, and a so-called “core framework” (CF) layer 16 (also referred to asa component framework layer), which includes a CF layer IDL 16 a and CFlayer services and applications 16 b. This layer structure helps toisolate the waveform applications from the radio hardware. The processorenvironment layer and the middleware layer are generally commerciallyavailable off-the-shelf products. The CF layer 16, however, which isdefined to be an open means to promote plug-and-play softwareinteroperability, has been developed by a number of different suppliers,including but not limited to Raytheon Corporation of Waltham, Mass., ITTIndustries of Clifton N.J., BAE Systems of the United Kingdom; BoeingCorporation of Chicago, Ill.; PrismTech of Woburn, Mass.; CommunicationsResource Center (CRCO) of Ottawa, Ontario Canada, and SelexCommunications of Italy, as well as universities such as the VirginiaPolytechnic Institute An exemplary prior art CF layer 16 implementationis application independent, but also can be platform dependent.

The CF layer 16 also is the essential set of open application interfacesand services that provide an abstraction of the underlying CommercialOff-The-Shelf (COTS) software and hardware. Portability is achieved byimplementing this same set of CF layer 16 application program interfaceson every platform. One purpose of the CF layer 16 is to deploy (load andexecute) a distributed application in a controlled and secured manner.At startup, the CF layer 16 reads information in the Domain Profile(described further below) and attempts to deploy a given application tothe platform, in accordance with relationships defined in the DomainProfile. Although the Domain Profile is not depicted in this figure, itis well understood by those skilled in the art and familiar with theSCA; further as those of skill in the art are aware, XML parsing of thedomain profile inherently is one of the services that the CF layer 16uses. The CF layer 16 is able to download a component (e.g., a softwarecomponent) to a device, couple components together to enable them tocommunicate, stop and start components, handle errors, and perform othermanagement tasks for the components. As illustrated in FIG. 3B, the CFlayer 16 includes a CF Interface Definition Language (IDL) 16 a and CFlayer services and applications 16 b. CF layer services 16 b, in oneexemplary prior art embodiment, consist of a Domain Manager thatimplements system control, a Device Manager that loads software andmanages a set of hardware devices, and core services such as Log, FileManager, and File System. The CF layer 16 also includes a domain managerthat managers the software applications, applications factories,hardware devices, and device manager. Although the details of the CFlayer's domain manager and service 16 b are not expressly illustrated inFIG. 3B, such services are known to those of skill in the art and,furthermore, are shown and described in further detail in theaforementioned SCA 2.2.2 Specification and '020 patent, which areincorporated by reference.

The aforementioned Domain Profile includes a set of files in eXtensibleMark-up Language (XML) format. As is known in the art, XML is a set ofrules for encoding documents in machine readable form. An XML parserparses an XML-encoded document so as to convert the XML-encoded documentinto an XML Document Object Model (DOM), which can then be manipulated(e.g., displayed in a browser), where the XML parser ensures that thedocument meets defined structures, validation, and constraints (whichcan be defined in a document type definition (DTD)). For example, theSCA defines XML DTDs for application, device, and service deploymentinformation, all of which are used by the SCA Domain Manager,Application Factory, and Device Manager components of the SCA. FIG. 6,described further herein, depicts the set of XML DTD types.

The Domain Profile is a hierarchical collection of XML files that definethe properties of all software components in the system and describesthe SCA system's components and connections between components anddescribes various aspects of the hardware and software devices making upthe SCA system, including the identity, capabilities, properties(including properties of embedded hardware devices), andinterdependencies, as well as information about the external interfacesof the components and devices, their implementations, and how they areconnected to form applications and platforms. An exemplary DomainProfile includes a set of descriptor files for describing theapplication (the Software Profile) and a set of descriptor files fordescribing the platform (the Device Profile).

Often the Domain Profiles can include a large amount of information(e.g., tens of thousands of lines of XML code spread over hundreds offiles). At runtime, the XML Domain Profile is read to get configurationand deployment information. The parsing of these XML Domain Profilefiles, and the interpretation of the parsed data by the SCA CF, loadssoftware components of the SCA and creates the connections between suchsoftware components and thus enables the radio to operate. The XMLDomain Profile can be parsed by the SCA CF layer 16 each time the SCAradio is turned on or when an application is installed into the radioDomain. The result, in some instances, is the requirement of multipledistributed software components within the radio Domain to parse XMLfiles.

One way the prior art CF layer 16 deploys the distributed application isthrough the use of CORBA. CORBA is the acronym for Common Object RequestBroker Architecture, which is a standard defined by the ObjectManagement Group (OMG) that enables software components written inmultiple computer languages and running on multiple computers to worktogether as a single application or set of services. CORBA uses aninterface definition language (IDL) to specify interfaces that objectswill present to the outside world, and specifies a mapping from the IDLto a specific implementation language. Because of the use of the CORBAdistributive middleware layer and Portable Operating System Interface(POSIX)-compatible open system environment, the CF layer 16 supportedcomponents can port with relative ease across different processors, RealTime Operating Systems (RTOSs), buses and Object Request Brokers (ORBs).Further information about CORBA can be found in the CORBA Specification,version 3.1 (January 2008), including Part 1 (CORBA Interface) and Part2 (Interoperability), available from the Object Management Group (OMG)),109 Highland Ave, Needham, Mass. 02494. The CORBA Specification ishereby incorporated by reference in its entirety.

Referring again to FIGS. 3A and 3B the middleware layer 14 typicallyincludes CORBA. (distributive middleware layer) and Real Time OperatingSystem (RTOS). As noted above, the prior art system of FIGS. 3A and 3B,as implemented in the '020 patent, also includes an embedded distributedXML parser that parses Domain profiles (which typically are defined inthe SCA) of the applications for more efficiently installing and runningthe application. The CF layer 16 Domain Management subsystem isadvantageously configured to invoke the XML parser only upon theinstallation of a new application or device.

SUMMARY OF THE INVENTION

The following presents a simplified summary in order to provide a basicunderstanding of one or more aspects of the invention. This summary isnot an extensive overview of the invention, and is neither intended toidentify key or critical elements of the invention, nor to delineate thescope thereof. Rather, the primary purpose of the summary is to presentsome concepts of the invention in a simplified form as a prelude to themore detailed description that is presented later.

One issue with at least some known implementations of the aforementionedSCA radio system is that the XML Document Object Model (DOM) validationparsers of the SCA generally are slow and large in code size and canrequire considerable General Purpose Processor (GPP) resources.

Various solutions have been proposed to provide an alternative to theway the existing XML DOM validation parsing function is provided, so asto improve speed and/or reduce the code size. Some proposed solutionsinvolve offline XML parsing and/or various types of preparsing, whichcan be advantageous if the platform and device resources are known priorto the time of waveform deployment.

One possible alternative involves offline XML parsing, where the XMLparsing is done at a time other than during run-time, such as during thesoftware installation process, and storing the parsed information in anon-XML file for use during future boots of the SCA system. Althoughoffline parsing can offer code size reduction, it requires defining aninterface between offline parsing and online processing of the parsedinformation, where XML introduced into the SCA system must bepre-validated.

An example of offline XML parsing includes a two-step parsing technique,wherein, in the first step, XML files are first translated, offline,into a translated format (e.g., a simple text or binary file) thatcontains only what is deemed to be the most important information forSCA core framework functionality from a given profile file (for example,keeping data required for successful deployment and configuration ofwaveforms and components, but discarding descriptions and headers). Thisresultant translated format can be SCA-compliant if it still has the setof XML files that accompanied the pre-processed XML files. In addition,this translated format can result in a smaller code-size footprint.Then, in the second step, the translated files are later parsed in realtime by the SCA core framework. This alternative has the potential toeliminate the XML parser from the SCA core framework.

Still another alternative involves optimizing XML parsing by pre-testingXML parsers against implemented files to determine which XML parser isthe most efficient in terms of system overhead, memory footprint, andparsing time, so as to select the “best” XML parser for a given set ofimplemented files, and also including pre-validation of XML files priorto installation within the SCA system, such that the parsed XML filesare not validated, thereby reducing code size.

A further alternative involves parsing XML files ahead of time andpre-processing the parsed XML files, so as to eliminate the XML parserfrom the SCA infrastructure. For example, the pre-processing can beconfigured to generate actual deployment code to deploy a waveform ontospecific hardware, which can be fast, but requires regeneration of allcode (i.e., re-parsing and re-preprocessing) if the waveforms must bemoved to a different platform. In the alternative, the XML domainprofile can be translated into a static binary format used by allwaveforms and platforms.

Accordingly, at least one embodiment of this invention described hereinproposes reducing this code size and processing time by replacing theXML parser and XML files with a CORBA parser and CORBA descriptor files,so as to effectively eliminate the XML parser within the SCA radiosystem.

In particular, the inventors of the instant application recognized thatbecause CORBA now has built in coding and decoding (CODEC) mechanisms,such CODEC mechanisms (along with other aspects of CORBA) can beadvantageous in implementing a system wherein the CORBA CODEC mechanismcan be used, along with other features, to create, effectively, a CORBAparser to replace the XML parser. Advantageously, using a CORBA parserand CORBA descriptor file to replace the XML parser and XML filesprovide significant improvements to any systems where XML parsing isused, including but not limited to SDR systems like the SCA SDR and/orany application that is using both CORBA and XML internally. Forexample, using a CORBA parser can greatly reduce the code size, improveparsing speed, and generally require fewer processing resources (freeingup the processing element for other radio-related tasks).

In addition, as described further herein, at least some embodiments ofthe invention provide a unique, advantageous preparsers tool located inthe offline environment (i.e., a tool that is running on a system thatis remote from the SDR system itself). For each type of descriptor (forexample, Device Configuration Descriptor (DCD), Domain ManagerDescriptor (DMD), and Software Assembly Descriptor (SAD)) used in theSCA, this offline preparsers tool preparses the XML files, including theXML descriptor files, using a COTS parser, then collapses the preparsedXML descriptor files into a corresponding CORBA structure (SAD, DCD, andDMD) that is encoded into a CORBA Common Data Representation (CDR) fileusing the CORBA CODEC factory. This resulting CDR file is provided tothe SDR system (also referred to herein as the embedded environment ortarget environment), which uses the CORBA CODEC factory to decode theCDR file and extract from it the resultant CORBA structure descriptors(e.g., SAD, DCD, DMD).

Advantageously, in at least some embodiments, when the XML informationis converted into CORBA property types during preparsing, the conversionis done such that the XML Properties (e.g., component instanceproperties for the different properties types) are converted to anappropriate core framework (CF) properties type, with correct valuestypes and in correct precedence order, so that no further conversion isrequired when they are used with an SDR system. (The precedence order iswell understood by those of skill in the art and is understood inconnection with the rules specified in SCA version 2.2.2 section D.2.1Software Package, D.6.1.3.3 componentinstantiation, concerningprecedence order.)

As those of skill in the art will appreciate, the above describedinventive preparsers tools and XML properties conversion features helpsto reduce code size and provide for more efficient operation of the SDRsystem, because these functions will no longer have to be done duringrun-time of the SDR system, but instead are done in an offlineenvironment.

For example, in accordance with one embodiment of the invention, XMLdeployment information is captured in the following CORBA structures:

Software Assembly Descriptor (SAD) structure, for an application thatrelates to SAD, Software Package Descriptors, (SPDs), Software ComponentDescriptors (SCDs), Application Deployment Descriptors (ADD), andProperties Descriptors (PRFs) SCA; DTDs;

Device Configuration Descriptor (DCD) structure, for Device Manager thatrelates to DCD, SPDs, Device Package Descriptors (DPD), SCDs and PRFsSCA DTDs; and

Domain Manager Configuration Descriptor (DMD) structure, for DomainManager that relates to SCA, DMD, SPD, SCD, Deployment PlatformDescriptor (PDD), PRFs, SCA DTDs.

These SAD, DCD, and DMD CORBA structures are defined based on the typesdefined by the existing core framework (CF) Parsers IDL interfaces forthe SCA, which interfaces are further explained herein, in the figuresand text, and further in the incorporated-by-reference computer programappendices, the incorporated-by-reference prior '720 patent, theincorporated-by-reference CORBA Specification, and in theincorporated-by-reference SCA Specification. Further, in accordance withat least one embodiment of the invention, if an interface or interfaceoperations are no longer needed by a given CF implementation, it isremoved from the interface since the XML parsing is done offline.

In still another embodiment, three respective pre-processor toolspre-parse Device Configuration Descriptor (DCD), Software AssemblyDescriptor (SAD), and Domain Manager Descriptor (DMD) XML files intorespective CORBA structures, then convert these respective CORBAstructures into respective CORBA encoded CDR files. Thus, for example,the SAD CORBA file contains a SAD encoded CDR CORBA structure (similarlytrue for DCD and DMD CORBA files). These preparsers tools parse andconvert the XML files into CORBA representation using, at least in part,the CF PreParsers IDL.

In addition, in at least one embodiment, the CF_Parsers IDL file ismodified by adding a local interface to its interface definitions, sothat only client code is generated (and not skeletal server side code).Further, with this embodiment, there need not be CORBA marshalling ofinterface operations (i.e., CORBA need not serialize objects associatedwith interface operations). For instances where the device manager isnot co-located with the domain manager, the local interface is optionalcompile directive.

In one embodiment, the invention provides a software architecture thatincludes a CORBA local parser interface; CORBA encoding for certainCORBA deployment types; pre-processor tools to convert XML into theCORBA deployment types and CORBA files; and, local parser interfaces forthe SCA SAD and DMD, optional for the DCD when Device Manager whennon-collocated with Domain Manager.

Furthermore, when using the core framework (CF) implementation describedherein in a system having a CF implementation based on one described inthe aforementioned '020 patent) at least one or more of the embodimentsof the invention described herein can be configured to have minimalimpact to such an the existing CF Domain Manager, Device Manager, andApplication Factory associated with the CF implementation based on the'020 patent, because the at least one or more embodiments, as describedherein, can be configured to use substantially similar interfaces, typesand operations. When the CF implementation described herein isimplemented as part of other types of CF systems, however, the impactmight be different.

In one embodiment, the invention provides a preparsers tool forconverting SCA XML files into CORBA structures usable by a SoftwareCommunication Architecture (SCA) Core Framework (CF), the preparserstool stored on a computer storage medium and configured to operate on aprocessor remote from the SCA CF. The preparsers tool comprises a coreframework (CF) CF_PreParsers interface definition language (IDL) and afirst type of preparser. The CF_PreParsers IDL is configured to be inoperable communication with an XML parser and with at least a first typeof preparser. The first type of preparser is in operable communicationwith the CF_PreParsers IDL, the first type of preparser associated witha first type of descriptor for the CF. The first type of preparser isconfigured to:

-   -   call the XML parser to request parsing of a first set of first        XML files, the first set of first XML files comprising a first        descriptor XML file corresponding to the first type of        descriptor and further comprising associated software package        descriptors (SPDs), software component descriptors (SCDs), and        Properties Descriptors (PRFs) XML files that are associated with        the first type of descriptor, as well as a first predetermined        set of additional descriptor XML files that are specifically        associated with the first type of descriptor;    -   convert the first parsed set of first XML files into a first        CORBA structure type, the first CORBA structure type based at        least in part on at least one predetermined type associated with        the SCA CF;    -   encode the first CORBA structure type into a first CORBA Common        Data Representation (CDR) file; and    -   write the first CORBA CDR to file as a first octet sequence.

In a further embodiment, within the first set of XML files, the firstdescriptor XML file is parsed prior to parsing any of the SPDs, SCDs,and PRF XML files. In still another embodiment, the CF_PreParsers IDLand the first type of preparser are configured to operate using the sameparser types as are used in the SCA CF.

In a further embodiment, the first type of preparser is furtherconfigured to:

-   -   condense the first parsed set of first XML files so as to remove        from the parsed set of XML files substantially all elements or        operations that are not required for deployment in the CF; and    -   convert the condensed first parsed set of first XML files, such        that the resulting first CORBA structure type contains only        elements required for deployment in the SCA CF.

In still another embodiment, the first type of preparser is furtherconfigured to convert the first parsed set of first XML files into afirst CORBA structure type such that the component instance propertiesare converted in accordance with predetermined values types andprecedence order, the predetermined values types and predeterminedprecedence order selected to ensure that the first CORBA structurerequires substantially no further conversion for it to be used in an SCACF system. In another embodiment, the predetermined values types andpredetermined precedence order correspond to values types and precedenceorder defined in at least one specification associated with the SCAsystem. In a further embodiment, the predetermined precedence ordercomprises configure properties, executable properties, resource factoryproperties, and options properties.

In still another embodiment, the first type of descriptor comprises asoftware assembly descriptor (SAD) and wherein the first predeterminedset of additional descriptor XML files comprises an applicationdeployment descriptor (ADD). For example, in another embodiment, the SADCORBA structure comprises CORBA elements that comprise:

-   -   id: string [1]    -   name: string [1]    -   partitions: PartitionsSequence [1]    -   assemblyControllerID: string [1]    -   connections: ConnectionsSequence [1]    -   externalPorts: ExternalPortsSequence [1]    -   deploymentPrefs: StringSequence [1]

In a further embodiment, the first type of descriptor comprises a deviceconfiguration descriptor (DCD) and wherein the first predetermined setof set of additional descriptor XML files comprises a device packagedescriptor (DPD). For example, in one embodiment, the DCD CORBAstructure comprises:

-   -   name: string [1]    -   partitions: PartitionsSequence [1]    -   connections: ConnectionsSequence [1]    -   domainManager: string [1]    -   fileSystemNames: FileSystemNames    -   id: string [1]

In yet another embodiment, the first type of descriptor comprises adomain manager configuration descriptor (DMD) and wherein the firstpredetermined set of set of additional descriptor XML files comprises adeployment platform descriptor (PDD). For example, in one embodiment,the DMD CORBA structure comprises

-   -   id: string [1]    -   props: Properties [1]    -   services: ServiceTypeSeq [1]    -   channels: ChannelTypeSeq [1]    -   name: string [1]

In a still further embodiment, the CF_PreParsers IDL is implemented ontop of XML. In another embodiment, the first type of preparser isfurther configured to:

-   -   convert the first CORBA structure type into a corresponding        first CORBA Any type;    -   encode the first CORBA Any type into a first CORBA octet        sequence; and    -   write the first CORBA octet sequence to a first encoded file.

In a further embodiment, the preparser tool is further configured toproduce a CORBA Common Data Representation (CDR) file capable of beinginstalled in the SCA CF and wherein the SCA CF is configured to:

-   -   acquire the first encoded file generated by the preparser tool;    -   decode the first CORBA octet sequence in the first encoded file        to form a second CORBA Any type, the second CORBA Any type        corresponding to the first CORBA Any type; and    -   convert the second CORBA Any type back into the first CORBA        structure type, the first CORBA structure type being usable by        the SCA CF.

In another aspect, the invention provides a preparsers tool forconverting SCA XML files into CORBA structures usable by a SoftwareCommunication Architecture (SCA) Core Framework (CF), the preparserstool stored on a computer storage medium and configured to operate on aprocessor remote from the SCA CF. The preparsers tool comprises a coreframework (CF) CF_PreParsers interface definition language (IDL) and aset of preparsers.

The CF_PreParsers IDL is configured to be in operable communication withan XML parser and with at least a first type of preparser. The set ofpreparsers is in operable communication with the CF_PreParsers IDL, theset of preparsers comprising a Software Assembly Descriptor (SAD)preparser, a Domain Manager Configuration Descriptor (DMD) preparser,and a Device Configuration Descriptor (DCD) preparser.

The SAD preparser is configured to:

-   -   call the XML parser to request parsing of a set of SAD XML        files, the set of SAD XML files comprising at least one SAD, at        least one Application Deployment Descriptor (ADD), at least one        Software Package Descriptor (SPD), at least one Software        Component Descriptor (SCD), and at least one Properties        Descriptor (PRF);    -   convert the parsed set of SAD XML files into a respective SAD        CORBA structure type;    -   encode the SAD CORBA structure type into a SAD CORBA Common Data        Representation (CDR) file; and    -   write the SAD CORBA CDR to file as a SAD octet sequence.

The DMD preparser is configured to:

-   -   call the XML parser to request parsing of a set of DMD XML        files, the set of DMD XML files comprising a DMD, an Deployment        Platform Descriptor (PDD), an SPD, an SCD, and a PRF;    -   convert the parsed set of DMD XML files into a respective DMD        CORBA structure type;    -   encode the DMD CORBA structure type into a DMD CORBA Common Data        Representation (CDR) file; and    -   write the DMD CORBA CDR to file as a DMD octet sequence.

The DCD preparser is configured to:

-   -   call the XML parser to request parsing of a set of DCD XML        files, the set of DCD XML files comprising a DCD, a Device        Package Descriptor (DPD), an SPD, an SCD, and a PRF;    -   convert the parsed set of DCD XML files into a respective DCD        CORBA structure type;    -   encode the DCD CORBA structure type into a DCD CORBA Common Data        Representation (CDR) file; and    -   write the DCD CORBA CDR to file as a DCD octet sequence.

In a further embodiment, the preparser tool is further configured to:

-   -   condense each respective SAD, DMD and DCD sets of parsed XML        files so as to retain in each parsed set of XML files any only        elements or operations that are required for deployment in the        CF; and    -   convert each respective condensed SAD, DMD, and DCD parsed set        of XML files, such that each respective resulting SAD, DMD, and        DCD CORBA structure type is substantially free of elements that        are not required for deployment in the SCA CF.

In still another aspect, the invention provides A SoftwareCommunications Architecture (SCA) Domain Profile usable by a SoftwareCommunications Architecture (SCA) CF, the SCA Domain Profile stored on acomputer storage medium and configured to operate on a processor. TheSCA Domain profile comprises a set of SCA XML files and correspondingCORBA encoded data files (CDRs) and a CF_Parsers. The set of SCA XMLfiles and corresponding CORBA CDRs comprise a Software AssemblyDescriptor (SAD) CDR, a Domain Manager Configuration Descriptor (DMD)CDR and a Device Configuration Descriptor (DCD) CDR, wherein each CDRcorresponds to a respective set of preparsed SAD, DMD, and DCD XMLfiles, wherein each respective set of preparsed SAD, DMD, and DCD XMLfiles is further configured to be substantially free of elements oroperations that are not required for deployment in the CF. TheCF_Parsers is in operable communication with the set of CORBA encodeddata files and with a client, the CF_Parsers configured to convert, uponreceiving request from the client, each respective SAD, DMD, and DCD CDRto a corresponding respective SAD, DMD, and DCD CORBA structure typethat is usable in the CF.

In a further embodiment, the CF_Parsers further comprises a selectablelocal interface, the selectable local interface configured to:

-   -   be selectable, at the time of compiling, to operate in a local        operational mode when the CF_Parsers and a client are in either        the same operating system process or the same operating system        partition; and    -   be selectable, at the time of compiling, to operate in a remote        distributive operational mode in one of the following two        situations:    -   (a) when the CF_Parsers and the client are in different        operating system processes from each other; and    -   (b) when the CF_Parsers and the client are in different        operating system partitions from each other.

Furthermore, the architectures and methods which are the subject of thisdisclosure can be used in conjunction with (and/or adapted to work with)the aforementioned Software Communications Architecture (SCA) forSoftware Defined Radio's (SDRs), both the existing 2.2/2.2.2.Specification and future Specifications (e.g., SCA Next and beyond), allof which are hereby incorporated by reference, as well as with theaforementioned systems described in the incorporated-by-reference '020patent. It is anticipated that at least some of the architectures andmethods of this disclosure also are applicable to other types of SDRs,including but no limited to the so-called open source GNU Radio system,as well as to other systems and devices that utilize principles of SDRand/or that use software components to communicate with differentwaveforms or protocols/standards, such as mobile/cellular telephones andother wireless network devices. It is further anticipated that at leastsome of the architectures and/or methods of this invention areapplicable to other technologies and/or domains that require alightweight deployment and configuration infrastructure, as well as anyapplication that is using CORBA and XML internally.

Details relating to this and other embodiments of the invention aredescribed more fully herein.

BRIEF DESCRIPTION OF THE FIGURES

The advantages and aspects of the present invention will be more fullyunderstood in conjunction with the following detailed description andaccompanying drawings, wherein:

FIG. 1 is a block diagram of a prior art SDR system;

FIG. 2 is a block diagram of a computer system in which at least oneembodiment of the present invention can be embodied;

FIG. 3A is a block diagram of a prior art SCA architecture, illustratingshowing the structure of its software architecture;

FIG. 3B is a block diagram showing the core framework (CF) layerinterface definition language (IDL) relationships of the prior artarchitecture of FIG. 3A;

FIG. 4 is a high-level block diagram showing the components of at leastone embodiment of the invention and further illustrating thisembodiment's comparison with and derivation from the prior art system ofFIGS. 3A and 3B and also its derivation from certain portions of theaforementioned U.S. Pat. No. 7,367,020;

FIG. 5 is a system block diagram of one embodiment of the invention;

FIG. 6 is a block diagram illustrating relationships between SCA XMLfiles to CORBA structures, in accordance with one embodiment of theinvention;

FIG. 7 is a first UML class diagram illustrating the optimized coreframework (CF) Parsers CORBA MODULE interfaces, in accordance with oneembodiment of the invention;

FIG. 8 is a second UML class diagram illustrating the CF PreParsersCORBA Module interfaces, in accordance with one embodiment of theinvention;

FIG. 9A is a block diagram illustrating interaction between thecomponents of FIG. 4 during operation of the Offline CF_PreParsers tool,including preparsing of SCA XML files and creation of CORBA Common DataRepresentation (CDR) files, in accordance with one embodiment of theinvention;

FIG. 9B is a first UML sequence diagram illustrating the operation ofOffline CF PreParsers tool, including instruction sequences embodyingthe block diagram of FIG. 9A, in accordance with one embodiment of theinvention;

FIG. 10A is a block diagram illustrating, in the Target EmbeddedEnvironment, interaction between the components of FIG. 4 duringoperation of the Embedded Optimize CF_Parsers, including reading in anddecoding of CORBA CDR files, in accordance with one embodiment of theinvention

FIG. 10B is a second UML sequence diagram illustrating the optimizedCF_Parsers Install application Illustration, including instructionsequences embodying the block diagram of FIG. 10A, in accordance withone embodiment of the invention;

FIG. 11 is a first flow chart illustrating a portion of the offlinemethod of operation of FIGS. 9A and 9B, in accordance with oneembodiment of the invention; and

FIG. 12 is a second flow chart illustrating a portion of the embeddedmethod of operation of FIGS. 10A and 10B, in accordance with oneembodiment of the invention.

The drawings are not necessarily to scale, emphasis instead generallybeing placed upon illustrating the principles of the invention.

DETAILED DESCRIPTION

It should be understood that, in the following detailed description,detailed explanations are not provided in every instance for terms ofart that can be located and explained in the aforementioned andincorporated-by-reference SCA specifications. For example, thedefinitions of the XML elements of the Software Assembly Descriptor(SAD) file and other descriptor files are not necessarily providedherein, as one of skill in the art will be expected either to know sucha definition already or to have the ability to refer to theaforementioned, publicly available SCA specification to obtain suchinformation.

In addition, in the following discussion, for clarity of description,exemplary listings of actual code used, in accordance with oneembodiment of the invention, to implement the various interfaces (e.g.,the interface definition language (IDL)), for example the core framework(CF) PreParsers IDL code, is not provided as part of the body of thetext. Rather, such code listings are provided as part of the includedcomputer program appendix.

Several illustrative embodiments of the invention will now be described.Referring now to the figures, FIG. 4 is a high-level block diagram 100showing the components of at least one embodiment of the invention andfurther illustrating this embodiment's comparison with and derivationfrom the prior art system of FIGS. 3A and 3B. As FIG. 4 illustrates, theprior art system of FIGS. 3A and 3B (which system was described moreparticularly in the aforementioned '020 patent), includes a distributedembedded parser 102, which includes a CF_Parsers module 104 that uses asits XML parser an open-source or COTS XML parser 106, which isillustrated by way of example only as being a Xerces parser.

In contrast, the optimized distributive embedded parser 108 of thisembodiment of the invention is at least partially derived from thedistributed embedded parser 104 of the aforementioned '020 patent, but,as will be explained further below, operates differently because it is,in fact, a CORBA parser. In addition, as explained further herein, theoptimized distributed embedded parser 108 provides an optional localinterface. The optimized distributed embedded parser 108 does notdirectly use the COTS XML parser 106 to perform XML parsing of the anyXML files that require parsing (e.g., application XML files, DomainProfile files, Software Assembly Descriptor (SAD) files, devicemanagers, etc.) within the SCA. Instead, as will be explained in furtherdetail herein, the optimized distributed embedded parser 108 usescertain features of CORBA, along with a new CF_PreParsers Offline XMLparser 114 (see FIGS. 5-12), to achieve XML parsing within the SCAenvironment.

Referring again to FIG. 4, the optimized distributed embedded parser 108includes an optimized CF_Parsers module 110 and the pre-parsedinformation from a new CF_PreParsers Offline XML parser 114 thatinherits from the optimized CF_Parsers module and uses this information,along with certain functionality of the CORBA Codec Factory 112, to(effectively) replace the prior art COTS XML parser 106 functionalitywith a new functionality able to parse XML files without requiring thatan XML parser be part of the embedded SCA environment. That is, inaccordance with at least one embodiment of the invention, no XML parsingtakes place within the SDR system. Note that the CF_PreParsers OfflineXML parser 114, as described further herein, can be configured, inaccordance with one or more embodiments of the invention, to run on anytype of computer configuration, including but not limited to computersystems 50 such as those described in connection with FIG. 2, herein. Inaddition, the Optimized CF_Parsers 110, as described further herein, canbe configured, in accordance with one or more embodiments of theinvention, to run within the SDR environment (e.g., the SDR system 20 ofFIG. 1, in particular as part of the SDR software component 24 and/orthe SDR client 22).

FIG. 5 is a system block diagram 200 of one embodiment of the invention,including illustrations of interactions between the embedded 202 andoffline 204 environments. Note that the interactions within the embedded202 and offline 204 environments are detailed further in FIGS. 9A and10A, respectively. Referring again to FIG. 5, the system 200 includes aTarget Embedded Environment 202 and an Offline Environment 204. TheTarget Embedded Environment 202 is the actual SDR system, radio or otherhardware device on which at least a portion of the SCA system 200 isrunning, i.e., the SCA environment, and can, for example be implementedas part of an SDR system 20 like that shown in FIG. 1. The Offlineenvironment 204 is illustrated in FIG. 5 as being implemented on acomputer environment running the Linux operating system, such as an x86platform running Linux. However, this should not be understood to belimiting. As those of skill in the art will appreciate, other types ofcomputers/processors running other types of operating systems (such ascomputer systems 50 described in connection with and shown in FIG. 2),e.g., Windows, Unix, Solaris, HP-UX, Mac OS X, Android, Symbian, etc.,are, of course, usable to implement the Offline Environment 204, as willbe appreciated by those of skill in the art.

The Target Embedded Environment 202 of FIG. 5 includes the coreframework (CF) 14, and an Optimized CF_Parsers 110 a (which is based onCORBA Interfaces and types). Both the Target Embedded Environment 202and the Offline Environment each include an Optimized CF_Parsers module110 (i.e., Optimized CF_Parsers 110 a in the Target Embedded Environment202 and Optimized CF_Parsers 110 b in the Offline Environment 204),where, as one of skill in the art would appreciate, the interface andfunctionality are adapted for the given environment (i.e., the same codeis used for the different environments). The Target Embedded Environment202 has access to a CORBA encoded CDR Files 206 (i.e., a file in a CORBACommon Data Representation (CDR)) that is created at the Offlineenvironment 204 (this is explained more fully herein). In addition, theTarget Embedded Environment 202 has access to the CORBA CODEC Factory212 (for decoding data) and a set of SCA XML files 214. Note that theSCA XML Files 214 are still required as being provided in thisembodiment, even though nothing is done with them, because the SCA hasdefined CF interfaces that reference such SCA XML files. However, inthis embodiment of the invention, all that is done with the SCA XMLfiles 214 is giving such SCA XML files 214 out on profile attribute CFinterface operations. The Optimized CF_Parsers 110 a of the TargetEmbedded Environment 202 is in operable communication with and uses theCORBA CODEC factory 212 during a CORBA decode operation, as describedfurther herein. The target embedded environment 202 may, of course,include other elements, but for simplicity these elements are not shownhere.

The Offline environment 204 is an environment defined to be external to,and distinct from, the Target Embedded Environment 202, and can beimplemented and run on a computer system (e.g., a computer systemsimilar to that of FIG. 2) that is separate/remote from the TargetEmbedded Environment 202. In one embodiment, the Offline Environment 204and the Embedded Environment 202 are located on physically distinct andseparate computer systems. That is, the Offline environment 204 is anenvironment defined by the fact that it runs independently from theembedded environment 202, although the Offline environment 204advantageously is able to create an encoded file (i.e., the CORBAEncoded CDR Data File 206) that will be accessible to the Embeddedenvironment 202. This does not necessarily require that the OfflineEnvironment 204 be in operable or direct communication with the Embeddedenvironment 202. Rather, as one of skill in the art will appreciate,there are various mechanisms to enable the file that is encoded by theOffline environment to be made accessible to the Embedded environment202. For example, in one embodiment, the CORBA Encoded CDR Data File206, created on the Offline environment 204, can be installed, moved, orcopied to the Embedded environment 202. In a further embodiment, theCORBA Encoded CDR Data File 206 created in the Offline environment 204is put in a remote location where the Embedded environment 202 canremotely access it. For example, the Embedded environment 202 andOffline environment 204 can communicate through a third party service,such as a network filing service (NFS), to enable the Embeddedenvironment 202 to access the CORBA Encoded CDR Data File 206.

The Offline Environment 204 includes an Optimized CF_Parsers IDLinterface 110 b and provides a PreParsers Tool for at least oneembodiment of the invention. The Offline Environment 204 also includes:a set of Device Configuration Descriptor (DCD), Domain ManagerConfiguration Descriptor (DMD) and Software Assembly Descriptor (SAD)SAD PreParsers 208 a, 208 b, 208 c, respectively; a CF_PreParsersInterface Definition Language (IDL) 114 that is implemented on top ofXML, and a low level parser 106 to parse the XML, shown by way ofillustration and not limitation as being the Xerces XML parser 106,where the low level parser receives and parses SCA XML files 202. TheCF_PreParsers IDL 210 definition is based upon the optimized CF_Parsers110 b definition, so the same parser types are used, thus making theOptimized CF_PreParsers tool 114 more efficient. The Linux Offlineenvironment 204 in which the Optimized CF_PreParsers Tool 114 isdisposed also has access to the CORBA CODEC factory 212 and the SCA XMLfiles 214 and generates the CORBA Encoded CDR Data File 206 (the CORBACODEC factory 212, CORBA Encoded CDR Data File 206, and SCA XML Files214 all are shown, for illustrative and not limiting purposes only, asbeing external to the Offline Environment 204). The DCD, DMD, and SADPreParsers 208 a, 208 b, 208 c, respectively, convert DCD, DMD and SADXML files, respectively, into DCD, DMD, and SAD CORBA encoded files(CDR) 206, respectively. This conversion is explained further herein, inconnection with FIGS. 6-12.

Referring again to FIGS. 4 and 5, in accordance with one embodiment ofthe invention, the basic CF_Parsers IDL 104, as described in theaforementioned incorporated by reference '020 patent, is adapted andmodified in at least some embodiments of the present invention to becomea CF_PreParsers module/tool 114 as well as an Optimized CF_Parsers 110a, 110 b, so that it instead converts XML into CORBA types, then putsthe CORBA types into a CORBA structure, where the information is storedinto new types that capture condensed/collapsed information into a CORBAstructure (i.e., a SAD structure, a DCD structure, and a DMD structure)(explained further in connection with FIG. 6). The SAD structure, DCDstructure, and DMD structure are all CORBA structure types that arebased upon existing CF_Parsers CORBA types and are shown and defined inFIGS. 6-12, described further below. In addition, at least someembodiments of the invention take advantage of certain features ofCORBA, such as the CORBA CODEC factory 212 and CORBA Anys. For example,it is known that the CORBA CODEC factory 212 provides encode/decodebehavior, so this CODEC factory 212 feature can be used to encode aCORBA_Any into an octet sequence, which can be written out to an encodedCORBA file. This is described further herein, especially in connectionwith FIGS. 8-11.

In addition, note that the computer program listing appendix on CD thataccompanies this filing, which CD and its contents are incorporated byreference, includes several non-executable, illustrative files (providedfor illustrative purposes only in Microsoft WORD format) that list thetext of several IDLs and other files that are useful in implementing atleast some embodiments of the invention. These files correspond to CORBAIDL files. One of skill in the art will recognize that although theCORBA IDL files are provided as text type documents, the actual textuallistings of the IDLs, together with the UML class diagrams of FIGS. 7and 8 (discussed further below), the known SCA and CORBA specifications,and routine skill in the art, can be used to help generate usable codeto implement at least some embodiments of the invention. For example, aCORBA Language (C, CPP, Java) IDL compiler can be used to convert theillustrated IDL into CORBA language mapping client and server files.

As an example, the computer program listing appendix on CD includes afile titled CF_Parsers_IDL.doc, which file provides a textual codelisting usable, in accordance with at least one embodiment of theinvention, to implement the optimized CF_Parsers 110 a, 110 b of FIG. 5.Similarly, the aforementioned computer program listing appendix on CDincludes a file titled CF_PreParsers_IDL.doc, which file provides anexemplary textual code listing usable, in accordance with at least oneembodiment of the invention, to implement the CF_PreParsers IDL 114 ofFIG. 5. Similarly, the aforementioned computer program listing appendixon CD includes a files titled DCD_IDL.doc, DMD_IDL.doc, and SADIDL.doc,as well as a DeviceConfigurationParser_IDL.doc,DomainManagerConfigurationParser_IDL.doc, andSoftwareAssemblyParser_IDL.doc, which files each provide respectiveexemplary textual code listings usable, in accordance with at least oneembodiment of the invention, to implement the corresponding DCDPreParsers 208 a, DMD PreParsers 208B, and SAD PreParsers 208 c, of FIG.5. Of course, those of skill in the art will appreciate that thesetextual code listings are merely exemplary and not limiting.

FIG. 6 is a block diagram 900 illustrating relationships between SCA XMLfiles to CORBA structures, in accordance with one embodiment of theinvention, where the traversal and conversion (which functions were donein the prior art at run-time) are now pre-processed, in accordance withan embodiment of the invention. In particular, the preparsing, thencollapsing/converting of the SCA XML files to CORBA structures that isshown in FIG. 6 actually takes place in the Offline environment 204, andthen the resulting CORBA structures that result are provided to theTarget/Embedded environment 202 in the form of encoded octet sequences.Note that the collapsing/converting referred to herein in connectionwith the CORBA structures includes pre-parsing of the XML files; thiswill be described further herein in connection with FIGS. 8-12.

Referring to FIGS. 5 and 6, the block diagram 900 of FIG. 6 shows theparticular SCA XML files that pre-parsed (e.g., using COTS parser 106)(step #'s 1-4 of Offline Environment 204 of FIG. 5) then are collapsedtogether, using, as applicable, the DCD PreParsers tool 208A, the DMDPreParsers tool 208B, and the SAD PreParsers tool 208C, to form theCORBA data structures 206, which structures include a SAD structure 318,a DCD structure 320, and DMD structure 322. Each CORBA structure isencoded into a respective CORBA encoded Common Data Representation (CDR)file 206 (e.g., resulting in the CDR file types SAD.cdr, DCD.cdr, andDMD.cdr) using CORBA CODEC 212 and Any mechanisms (e.g., as shown instep #5 in Offline Environment 304 of FIG. 5), and written to file as anoctet sequence (step #6 in Offline Environment of FIG. 5). As shown inFIG. 5, the octet sequence is provided to the CORBA encoded CDR datafile 206 in the Embedded Environment 202, which reads in the encodedCORBA octet sequence from the CORBA Encoded CDR Data File 206 (step #2in Embedded Environment 202 of FIG. 5) and also uses the CORBA CODECfactory 212 to decode the CORBA Encoded CDR data file (step #3 inEmbedded Environment 202 of FIG. 5) and extract from it the resultantdescriptor files (e.g., SAD, DCD, DMD).

Referring again to FIG. 6, the block diagram 900 of FIG. 6 alsoillustrates, in a manner similar to that used in UML diagrams, themultiplicity relationships between the XML files that are parsed tocreate the structures. The particular SCA XML descriptors/files of FIG.6 are not discussed in great detail herein, as those of skill in the artwill recognize the functions of and details about each of the types ofdescriptor files shown in FIG. 6 are discussed in the aforementioned,incorporated-by-reference SCA specification, especially in its AppendixA-Glossary, and also in the SCA 2.2.2 extensions. Note also that SCANext Specification also provides further information about thedescriptor files.

Advantageously, in at least some embodiments, when the XML informationof the SCA XML files is converted into CORBA CF property types duringpreparsing, the conversion is done such that the XML Propertiesassociated with each component (e.g., Configure Properties, ExecutableProperties, Resource Factory Properties, Options Properties, and othercomponent instance properties) are each converted to a respectivecorrect SCA CF::Properties type, with correct precedence order, so thatno further conversion is necessary when the converted XML file used witha radio or other SDR system. The properties returned are converted tothe proper CORBA types from their string types (found in XML). (This ismore particularly illustrated in the included computer program listingin the CF_PreParsers_IDL.doc, at about page 7). That is, as those ofskill in the art know, in XML there is a precedence of four levels forany given property, and the pre-processing done in the OfflineEnvironment 204 handles the precedence order for each property to ensurethat the property obeys the precedence list requirement. The precedenceorder is well understood by those of skill in the art and is understoodin connection with the rules specified in SCA version 2.2/2.2.2, sectionD.6.1.3.3, concerning precedence order.

This technique of converting to SCA CF::Properties type, with correctprecedence order, provides efficiency advantages over prior art systemsthat convert XML information into SCA CF::Properties types duringruntime, and also provides advantages over prior art systems that do notconvert XML information into SCA CF::Properties types in correctprecedence order.

As a first example of creation of a CORBA structure, in accordance withone embodiment of the invention, consider, for example, the DCDstructure 320, created using DCD PreParsers tool 208A (an illustrativeexample of which is documented in the included computer program listingappendix, which forms part of this application, as DCD_IDL. Note thatthe preparser DCD tool 208A uses this DCD_IDL structure, such that theIDL-generated code becomes part of the tool. With the DCD PreParserstool 208A, the Device Configuration Descriptor (DCD) 922 and itsassociated Software Package Descriptors (SPD) 908, Software ComponentDescriptors (SCD) 910, Device Package Descriptors (DPD) 924 andProperties Descriptor (PRF) 926 XML files are collapsed together so asto be converted into the CORBA DCD structure 320. The CORBA structure isfurther encoded into CDR and then written to file as an octet sequence,as described above and further herein.

Referring again to FIGS. 5 and 6, an example of the resultant DCDstructure 320, when collapsed in accordance with an embodiment of theinvention, is shown below and also in FIG. 7, which is a first UML classdiagram 300 illustrating the optimized CF Parsers CORBA moduleinterfaces and structures, including various CORBA elements used intheir definitions, and provides an overview of the interfacerelationships, in accordance with one embodiment of the invention. ThisDCD structure 320 is the structure that represents the collapsing of theDCD XML files after these DCD XML files have been preparsed (i.e., theDCD 922, and its associate DPD 924, PD 926, SPD 908 and SCD 910 XMLfiles) as discussed above in connection with FIG. 6. The DCD structure320 is the structure that contains the information about a devicemanager created by the preparser parsing the DCD XML file and is used bythe CF_Optimized CF_PreParsers 114.

Referring now to FIGS. 5-7, in forming the DCD structure 320, the DCD922 pulls in the 1 to N associated SPDs 908 (i.e., it pulls in howevermany there are up to “N”, but will pull in at least one). In addition,the DCD indirectly pulls in SCDs 910 and PRFs 926, because each of the 1to N associated SPDs 908 pulled by the DCD 922 will itself pull, foreach SPD 908, from 0 to 1 single respective SCDs 910; the DCD 922 alsopulls in from 0 to N DPDs 924, and for each of the 0 to N DPDs 924, eachrespective DPD 924 pulls in from 0 to 1 single respective PRFs 926.

This DCD structure 320 and its illustrated elements is a representationthat conveys everything of importance that was contained in the originalSCA XML files. As shown in FIG. 7 (and as also included in the computerprogram listing appendix, in the DCD_IDL file), the exemplary DCDstructure 320 includes as elements:

-   -   id: string [1]    -   name: string [1]    -   partitions: PartitionsSequence [1]    -   connections: ConnectionsSequence [1]    -   domainManager: string [1]    -   fileSystemNames: FileSystemNamesSeq [1]

This DCD structure 320 is provided as an example usable in accordancewith at least some embodiments of the invention and is not intended aslimiting. Each of the elements of the DCD structure 320 (as well as theSAD structure 318 and DMD structure 322, discussed further below) willbe readily understood by one of skill in the art when viewed inconnection with the aforementioned, incorporated-by-reference SCASpecification and the included computer program listing appendix. Forexample, the domainManager element indicates how to obtain theCF::DomainManager object reference, and the fileSystemNames elementindicates the mounted file system names for CF::DeviceManager'sFileManager. As will be apparent, advantageously, this DCD structure 320does not include or require elements/items that have nothing to do with(i.e., are not needed for) deployment and/or that are merelyinformational elements/items. Thus, in at least one embodiment the DCDstructure 320 contains only elements required for deployment in the SCACore Framework (CF) 16. Of course, one of skill in the art willappreciate that the DCD structure 320 (as well as the SAD structure 318and DMD structure 322, described further herein) could, in an alternateembodiment, be implemented to include additional items, such asnon-deployment items and merely informational items, but the resultingstructure might not be as compact as the DCD structure 320 illustratedin FIG. 7. In addition, those of skill in the art will readily be ableto determine, for a given deployment, which elements in the DCDstructure 320 are not required for that given deployment; this also willbe true for the SAD structure 318 and DMD structure 322 furtherdescribed herein.

Referring again to FIGS. 6 and 7, the SAD structure 318 and DMDstructure 322 are formed in a manner similar to that for the DCDstructure 320, which method is also discussed further below inconnection with FIGS. 8-12. Consider first the SAD structure 318. Usingthe SAD PreParsers tool 208B (an illustrative example of which isdocumented in the included computer program listing appendix asSAD_IDL.doc), the Software Assembly Descriptor (SAD) 904 and itsassociated SADs, SPDs 908, SCDs 910, Application Deployment Descriptors(APDs) 906 and PRF 926 XML files are collapsed together so as to beconverted into the CORBA SAD structure 318.

An example of the resultant SAD structure 318, when collapsed inaccordance with an embodiment of the invention, is shown below and inFIG. 7. This SAD structure 318 is the structure that represents thecollapsing of the SAD XML files as discussed above in a similar mannerfor the DCD structure 320. The SAD structure 318 is the structure thatcontains the information created by the pre parser parsing the SAD XMLfile. The SAD structure 318 is used by the Optimized CF_Parsers 110. TheSAD 904 corresponds to the Software Assembly Descriptor (SAD) DTD XMLfile and the SAD elements map to the concepts in the SAD 318. As withthe DCD structure 320, the SAD structure 318 and its illustratedelements is a representation that conveys everything of importance thatwas contained in the original SCA XMLs. Referring again to FIGS. 6 and7, in forming the SAD structure 318, the SAD 904 pulls in at least anSPD or an SAD, and there can be N of these; for example, the SAD 904 canpull in the 0 to N associated SPDs 908 (i.e., it pulls in however manythere are up to “N”, but there may be none). Optionally, the SAD 904 canpull in zero or one SCDs. The SAD 904 must be able to pull in at leastone member from one of these two sets SAD and SPD. In addition, each ofthe 0 to N associated SPDs 908 will itself pull, for each SPD 908, from0 to 1 single respective SCDs 910. The SAD 904 also pulls in from 0 to 1Application Deployment Descriptors (ADD) 906.

As shown in FIG. 7 (and as also included in the computer program listingappendix), the exemplary SAD structure 318 includes as elements:

-   -   id: string [1]    -   name: string [1]    -   partitions: PartitionsSequence [1]    -   assemblyControllerID: string [1]    -   connections: ConnectionsSequence [1]    -   externalPorts: ExternalPortsSequence [1]    -   deploymentPrefs: StringSequence [1]

As noted above, each of the elements of the SAD structure 318 will bereadily understood by one of skill in the art when viewed in connectionwith the aforementioned, incorporated-by-reference SCA Specification andthe included computer program listing appendix. For example, thereadonly assemblyControllerld attribute corresponds to the SAD DTDassemblycontroller element within the SAD file. The readonlyexternalPorts attribute corresponds to the SAD DTD externalports elementwith the SAD file. As with the DCD structure 320, the SAD structure 318advantageously only includes items required for a given deployment andthus does not include or require elements that are unnecessary fordeployment and/or that are merely informational.

Referring again to FIGS. 6 and 7, consider next the DMD structure 322.Using the DMD PreParsers tool 208C (an illustrative example of which isdocumented in the included computer program listing appendix asDMD_IDL.doc), the Domain Manager Configuration Descriptor (DMD) 930 andits associated SPDs 908, SCDs 910, Deployment Platform Descriptor 932,and PRF 926 XML files are collapsed together so as to be converted intothe CORBA DMD structure 322.

An example of the resultant DMD structure 322 when collapsed inaccordance with an embodiment of the invention, is shown below and inFIG. 7. This DMD structure 322 is the structure that represents thecollapsing of the DMD XML files as discussed above in a similar mannerfor the DCD structure 320. As with the DCD structure, the DMD structure322 and its illustrated elements is a representation that conveyseverything of importance that was contained in the original SCA XMLs.Referring again to FIGS. 6 and 7, in forming the DMD structure 322, theDMD 930 pulls in the 0 to 1 associated Deployment Platform Descriptor(PDD) 932, at least one SPD 908, from 0 to 1 SCD 910, and, from 0 to NPRF 926.

As shown in FIG. 7 (and as also included in the computer program listingappendix), the exemplary DMD structure 320 includes as elements:

-   -   id: string [1]    -   props: Properties [1]    -   services: ServiceTypeSeq [1]    -   channels: ChannelTypeSeq [1]    -   name: string [1]

As noted above, each of the elements of the DMD structure 322 will bereadily understood by one of skill in the art when viewed in connectionwith the aforementioned, incorporated-by-reference SCA Specification andthe included computer program listing appendix. As with the DCDstructure 320, the DMD structure 322 advantageously does not include orrequire elements that are unnecessary for deployment and/or that aremerely informational, and, in accordance with at least one embodiment ofthe invention, includes only elements required for deployment. Note thatthe embodiment of the invention that include the aforementioned CORBAstructures are applicable to virtually all SCA extensions, even thosenot illustrated with particularity in this patent application.

Referring more particularly to FIG. 7, this figure includes a first UMLclass diagram 300 illustrating the optimized CF_Parsers CORBA moduleinterfaces and structures, including various CORBA elements used intheir definitions, and provides an overview of the interfacerelationships, in accordance with one embodiment of the invention. Inparticular, the first UML class diagram 300 of FIG. 7 illustratesinterface, classes and relationships related to the parsing activitiesof the UML Sequence chart of FIG. 10B, described later herein. Inaddition, FIG. 8 is a second UML class diagram 400 illustrating theCF_PreParsers CORBA Module interfaces, including interfaces, CORBAelements, CORBA constants, and CORBA sequences, used in connection withpreparsing, in accordance with one embodiment of the invention. That is,the second UML class diagram 400 of FIG. 8 illustrates interfaces andrelationships used during the preparsing activities of the UML Sequencechart of FIG. 9B, described later herein (these activities also includecreation of the aforementioned SAD structure 318, DCD structure 320, andDMD structure 322). The CF_(—) PreParsers is 114 based upon interfacesand types from the optimized CF_Parsers 110, so compatible types andinterfaces are defined once. This allows the encoding and decoding to beusing the same types for SAD, DCD, and DMD.

Referring briefly to FIG. 7, at a high level, in this first UML diagram300, the CORBA module interfaces include a Parser interface 304, anAssemblyParser interface 306, a PropertiesParser interface 308, aSoftwarePackageParser interface 310, a SoftwareAssemblyParser interface312, a DeviceConfigurationParser interface 314, and aDomainManagerConfigurationParser interface 316. The UML class diagram300 of FIG. 7 also illustrates the aforementioned CORBA structures thatdefine the attributes of the aforementioned Software Assembly Descriptor(SAD) structure 318, Device Configuration Descriptor structure (DCD)structure 320, and Domain Manager Configuration Descriptor (DMD)structure 322. The AssemblyParser interface 306 and theDomainManagerConfigurationParser 316 interface each inherit from theParser interface 304. The SoftwareAssemblyParser interface 312 and theDeviceConfigurationParser interface 314 each inherit from theAssemblyParser interface 306. The AssemblyParser interface 306 has adependency on the PropertiesParser interface 308 and theSoftwarePackageParser interface 310. These types of dependencies can beused in building up Partitions. The DCD CORBA structure 320 and the SADCORBA structure 318 each uses information from the AssemblyParserinterface 306.

In addition, as will be appreciated by those of skill in the art, thefirst UML class diagram 300 of FIG. 7 updates and modifies in severalplaces the middleware layer parser interfaces definitions shown in FIG.4 of the aforementioned '020 patent in several ways. For example, theoptimized CF_Parsers_IDL 110 of FIG. 4 of the instant applicationadvantageously only has the bare minimum behavior needed for decodingthe SAD, DCD, and DMD and retrieving the information, whereas theCF_PreParsers 114 (of FIG. 8) includes all the information needed toparse the various XML files. Further, one of skill in the art willrecognize that because details regarding at least some of the elementswithin the interfaces are explained further in the aforementioned,incorporated-by-reference SCA specification, these details are notrepeated here in every instance, for purposes of clarity. In addition,details and implementation of the interfaces and elements shown in FIGS.7 and 8 is further illustrated in the files included with the computerprogram listing appendix that form part of this application.

Referring briefly to FIG. 8, at a high level, in the second UML diagram400 of FIG. 8, the CF_PreParsers CORBA Module Interfaces include aParser interface 404, an AssemblyParser interface 406, aCF_Parsers::AssemblyParser interface 407 (which is the same as theAssembly Parser interface 306 of FIG. 7), a PropertiesParser interface408, a CF_Parsers::PropertiesParser interface 409 (which is the same asthe PropertiesParser interface 308 of FIG. 7), a SoftwarePackageParserinterface 410, a SoftwareAssemblyParser interface 412, aDomainManagerConfigurationParser interface 414, aDomainManagerConfigurationParser interface 416, a PackageParserinterface 418, a DevicePackageParser interface 422, and aSoftwareComponentParser 424.

In FIG. 8, the AssemblyParser interface 410, the PropertiesParserinterface 408, the SoftwareComponentParserinterface 424, thePackageParser interface 418 and the DomainManagerConfigurationParser 416each inherit from the Parser interface 404 (each of these elements isexplained further below). The SoftwareAssemblyParser interface 412 andthe DeviceConfigurationParser interface 414 each inherit from theAssemblyParser interface 406. The SoftwarePackageParser interface 410and the DevicePackageParser interface 422 each inherit from thePackageParser interface 418.

The Parser interface 404 of FIG. 8 (CF_PreParsers/Offline Environment)is somewhat similar to the Parser interface 304 of FIG. 7(CF_Parsers/Embedded Environment), but is adapted, of course, for theOffline Environment and, for example, can use different methods. Forexample, in FIG. 7, the Parser interface 304 defines the commonattributes and operations for all CORBA parsers. The parseFile methodused in the Parser interface 304 of FIG. 7 parses the input file andverifies that the input file is well formed and valid encoded file. InFIG. 8, the PreParseFile method of the Parser interface 404 of FIG. 8calls the offline XML parser (e.g., Xerces parser 206) to parse the SCAXML files 214 (e.g., so as to be used during formation of theaforementioned CORBA structures).

Similarly, the AssemblyParser interface 306 of FIG. 7 (CF_Parsers,Embedded Environment) is somewhat similar to the AssemblyParserinterface 406 of FIG. 8 (CF_PreParsers, Target Environment), but eachAssemblyParser interface is adapted for each environment. For example,the AssemblyParser interface 306 of FIG. 7 and 406 of FIG. 8 eachcontains common operations and attributes for retrieving common elementsthat an assembly type (e.g., DCD and SAD) file consist of and has commonelements such as partitions and connections elements. In FIG. 8, theAssemblyParser interface 406 includes further methods and also usesdefinitions from the AssemblyParser interface 406 of the EmbeddedEnvironment of FIG. 7 (e.g., via the CF_Parsers::AssemblyParserinterface 407). That is, the AssemblyParser interface 406 of FIG. 8depends on the CF_Parsers::AssemblyParser interface 407, where theAssemblyParser interface 306 is a member function of the CF Parser classof FIG. 7.

The AssemblyParser interface 406 of FIG. 8 includes severalmethods/operations, all further described in the includedCF_PreParsers_IDL.doc in the Computer Program Appendix. ThecomponentInitialConfigProperties operation returns the set ofconfiguration properties that are used for the initial configuration ofthis component after execution. The properties returned have beenconverted to the proper CORBA types from their string types (found inXML). The conversion is based on the type attribute defined in theSimpleType. The getComponentExecuteProperties operation returns the setof execute properties that are used for executing a component. Theproperties returned have been converted to the proper CORBA types fromtheir string types (found in XML). The conversion is based on the typeattribute defined in the SimpleType.

The getComponentResourceFactoryProperties operation returns the set ofproperties associated with an instance of the resource and are to besent to the resourceFactory when the instance is created. The propertiesreturned have been converted to the proper CORBA types from their stringtypes (found in XML). The conversion is based on the type attributedefined in the SimpleType. This operation adheres to the rules specifiedin SCA version 2.2/2.2.2, section D.6.1.3.3, concerning precedenceorder.

Similarly, the PropertiesParser 308 of FIG. 7 and the PropertiesParser408 of FIG. 8 are somewhat similar, but each is adapted for therespective environment, i.e., the Embedded Environment for thePropertiesParser 308 of FIG. 7 and the Offline Environment for thePropertiesParser 408 of FIG. 8. The PropertiesParser 308, 408 of FIGS. 7and 8 is an interface for a property file (.prf) parser. A property filecan be referenced by a Software Package Descriptor 908(SPD; see FIG. 6)or Software Component Descriptor 910(SCD; see FIG. 6) XML file or aDevice Package Descriptor 924 (DPD; see FIG. 6) XML file. The SPDdescribes implementation(s) of a specific component. The SCD describesas CORBA-capable software component and its interfaces. The DevicePackage Descriptor identifies a class of device. The PropertiesParserinterface 408 of FIG. 8 inherits from the CF_Parsers::PropertiesParserinterface 409 (i.e., uses definitions from the PropertiesParser 304 ofthe Embedded Environment of FIG. 7). A property file can be referencedby an assembly, component, or component instantiation and containsproperty elements.

The SoftwarePackageParser interface 310 of FIG. 7 and 410 of FIG. 8 ispart of an XML parser interface for a Software Package Descriptor (SPD)parser. The SPD is used at deployment time to load and execute a SCAcompliant component and its various implementations.

Referring again to FIGS. 7 and 8, the SoftwareAssemblyParser interface312 (of FIG. 7) and 412 (of FIG. 8) defines the operations to parse andretrieve information from a Software Assembly Descriptor (SAD) XML filethat conforms to the SAD DTD. As with the other interfaces that arepresent in both the Offline and Embedded environments, eachSoftwareAssemblyParser interface 312 (of FIG. 7) and 412 (of FIG. 8) istailored to the environment (Embedded or Offline) in which it isimplemented. The SAD describes the deployment characteristics andconnectivity of components. The SoftwareAssemblyParser interface 312/412extends the AssemblyParser interface 306 by adding specific behavior andtypes for a SAD DTD, including several attributes. In FIG. 7, theSoftwareAssemblyParser interface 312 is used by the optimized CF_Parser110 to parse the data in a SAD CDR file created by the OptimizedCF_PreParsers 114. The readonly assemblyControllerld attributecorresponds to the SAD DTD assemblycontroller element within the SADfile. The readonly externalPorts attribute corresponds to the SAD DTDexternalports element with the SAD file. This attribute is an optionalelement within the SAD DTD, therefore an empty set is valid.

In addition, as noted below, for the SoftwareAssemblyParser interface312 of FIG. 7, (like the DomainManagerConfigurationParser interface 316,described below), the local interface can have a compiler directive ifneeded. CORBA inherently has a local interface mechanism. The OptimizedCF_Parser 110 described herein is intended to reside within the SDRsystem 20 (FIG. 1), but, the Optimized CF_Parsers 110 can be local orremote (i.e., non-local), that is, the Optimized CF_Parsers 110 can havelocal or remote distribute behavior between the client and optimizedCF_Parsers 110 components (e.g., between the SDR client 22 and the SDRsoftware component 24). For example, the Optimized CF_Parsers 110, inone embodiment of the invention can be co-located with an SDR client(e.g., SDR client 22 of FIG. 1) that is calling the parsing behavior.Being “collocated” or “local” means that the SDR client 22 and theoptimized CF_Parsers 110 are in the same operating systemprocess/partition. If that is the case, then the Optimized CF_Parsers110 has local behavior. If, however, the SDR client and the OptimizedCF_Parsers 110 are remote (such as when the Optimized CF_Parsers 110 isin a different operating system process/partition than the SDR client22), then the optimized CF_Parsers 110 behavior is said to be remoteservice and client's CF_Parsers are marshaled CORBA requests.

Referring to FIGS. 7-8, the DeviceConfigurationParser interface 314(FIG. 7), 414 (FIG. 8) defines the operations to parse and retrieveinformation from a Device Configuration Descriptor (DCD) file. The DCD922 identifies components that will initially start on a device,information about the devices associated with a device manager and howto find the domain manager, as well as the configuration information fora device. As with the other interfaces that are present in both theOffline and Embedded environments, each DeviceConfigurationParserinterface 314 (of FIG. 7) and 414 (of FIG. 8) is tailored to theenvironment (Embedded or Offline) in which it is implemented. Forexample, in FIG. 8, the DeviceConfigurationParser interface 414 extendsthe AssemblyParser interface 406 and Parser interface 404 by addingspecific behavior and types for a DCD DTD. In addition, in the Embeddedenvironment of FIG. 7, the DeviceConfigurationParser 314 is used by theoptimized CF_Parsers 110 to parse the data in a DCD CDR file created bythe optimized CF_PreParsers 114. The domainmanager element of theDeviceConfigurationParser interface 414 of FIG. 8 indicates how toobtain the CF::DomainManager object reference. The filesystemnameselement of the DeviceConfigurationParser interface 414 of FIG. 8indicates the mounted file system names for CF::DeviceManager'sFileManager. The devicemanagersoftpkg element of theDeviceConfigurationParser interface 414 of FIG. 8 refers to the SPD 908for the CF DeviceManager.

In addition, in one embodiment, the DeviceConfigurationParser interface314/414 can include an optional (not illustrated in FIG. 7 or 8),read-only, connections attribute, which the attribute corresponds to theDCD DTD connections element within the DCD file 922. This isillustrated, indirectly in FIG. 8 by inheritance: theDeviceConfigurationParser interface 414 inherits from the AssemblyParser interface 406, which inherits from CF_Parsers::AssemblyParser407. This attribute is an optional element within the DCD DTD, thereforean empty set is valid. The connections attribute is intended to providethe connection map between components in the assembly.

Still referring to FIGS. 7-8, the DomainManagerConfigurationParserinterface 316 (FIG. 7) and 416 (FIG. 8) defines the operations to parseand retrieve information from a DomainManager Configuration Descriptor(DMD) XML file 930 that conforms to the DMD DTD. As with the otherinterfaces that are present in both the Offline and Embeddedenvironments, each DomainManagerConfigurationParser interface 316 (ofFIG. 7) and 416 (of FIG. 8) is tailored to the environment (Embedded orOffline) in which it is implemented. TheDomainManagerConfigurationParser interface 316/416 extends the Parserinterface 304/404 by adding specific behavior and types for a DMD DTD.The services type of the DomainmanagerConfigurationParser interface 316of corresponds to the service element definition in the DMD DTD. It'sused by the CF DomainManager to determine which service (Log, etc.)instances to use; it makes use of the service element in the DTD.

Referring to FIG. 8, the PackageParser interface 418 contains operationsand attributes for retrieving common elements that an XML package type(e.g., Device Package Descriptor (DPD) 924, Software Package Descriptor(SPD) file 908) consists of, such as author and title elements. The DPD924 identifies a class of device.

Other embodiments can, of course, include additional interfaces andclasses. For example, in one embodiment there is a PackageParserinterface 412 that contains operations and attributes for retrievingcommon elements that an XML package type (e.g., DPD, SPD) file consistsof, such as author and title elements. The SoftwarePackageParser 310inherits from the PackageParser 412, and the SoftwarePackageParser 310parsers an SPD 908.

As noted above, FIGS. 7 and 8 also illustrate how an IDL Compilerdirective can control whether the CF parser IDL interface is local ornot. The ability to provide a local interface in the optimizedCF_Parsers 110 is optional, and providing a local interface for theoptimized CF_Parsers 110 is done for certain interfaces in cases wherethe Device Manager is not collocated with the Domain Manager. Forexample, in the exemplary embodiment of FIG. 7, an optional newconstraint, namely the islocal=True/False, is added to each of theSoftwareAssemblyParser interface 312 andDomainManagerConfigurationParser interface 316. This UML constraint iscontrolled by an IDL Compiler Directive, which controls whether theparticular interface is local or not. In FIG. 8, the constraint isLocalis set to TRUE. The local interface is controlled by compile directive:

#ifdef CORBA_LOCAL

local

#endif

If the CORBA_LOCAL symbol is defined then local is used. The IDLcompiler option allows for a symbol to be defined during compilation.That is, the compile directives allows choices when compiling the IDL,so generated code can be generated differently depending on theCORBA_LOCAL being defined or not.

For example, in one embodiment, the local interface feature isimplemented via a modification to the CF_Parsers at IDL compile time. Insuch an embodiment, the SCA domain profile includes a set of SCA XMLfiles and corresponding CORBA encoded data files (CDRs), the set ofCORBA CDRs including a Software Assembly Descriptor (SAD) CDR, a DomainManager Configuration Descriptor (DMD) CDR and a Device ConfigurationDescriptor (DCD) CDR. Each CDR corresponds to a respective set ofpreparsed SAD, DMD, and DCD XML files, wherein each respective set ofpreparsed SAD, DMD, and DCD XML files is, advantageously, furtherconfigured to be substantially free of elements or operations that arenot required for deployment in the CF. The CF_Parsers is in operablecommunication with the set of CORBA encoded data files and with aclient. The CF_Parsers configured to convert, upon receiving requestfrom the client, each respective SAD, DMD, and DCD CDR to acorresponding respective SAD, DMD, and DCD CORBA structure type that isusable in the CF. In the CF_Parsers, a selectable local interface isincluded for the DeviceManagerParser interface but can also be extendedto other Parser interfaces. This selectable local interface isconfigured to be selectable, at the time of compiling, to operate in alocal operational mode when the CF_Parsers, Domain Manager and DeviceManager clients are in either the same operating system process or thesame operating system partition. In addition, the selectable localinterface is configured to be selectable, at the time of compiling, tooperate in a remote distributive operational mode in one of thefollowing two situations: (a) when the CF_Parsers and the clients are indifferent operating system processes from each other; and (b) when theCF_Parsers and the client are in different operating system partitionsfrom each other.

Those of skill in the art will note that the aforementioned codelistings in the incorporated-by-reference CD of computer programlistings provide further details as to the particulars of the types,exceptions, input parameters, and methods of the various interfacesshown in the UML diagrams 300 and 400 of FIGS. 6 and 7, respectively, asimplemented in accordance with one or more exemplary and non-limitingembodiments of the invention, which listings will be readily understoodby one of skill in the art.

FIG. 9A is a block diagram 450 illustrating interaction betweencomponents of FIGS. 4 and 5 during operation of the OfflineCF_PreParsers tool 114, including preparsing of SCA XML files 214 andcreation of CORBA structures and the CORBA Encoded Data (CDR) file 206,in accordance with one embodiment of the invention. FIG. 9B is a firstUML sequence diagram 500 that further illustrates operation of theOffline CF PreParsers tool 114, in accordance with one embodiment of theinvention. FIG. 10A is a block diagram illustrating interaction betweencomponents of FIGS. 4 and 5 during operation of the Embedded CF_Parserstool 110, in accordance with one embodiment of the invention. FIG. 10Bis a second UML sequence diagram 600 that further illustrates operationof the Embedded CF Parsers tool 110, in accordance with one embodimentof the invention. FIGS. 11 and 12 are first and second flow chartsillustrating, respectively, first and second methods of operation inaccordance with one embodiment of the invention, where the method ofFIG. 11 embodies the signal flow and sequences of FIGS. 9A-9B, and wherethe method of FIG. 12 embodies the signal flow and sequences of FIGS.10A-10B. FIGS. 9A-12 are discussed in greater detail below.

Although the following discussion uses the example of the SAD structure318, the operations and signal flow discussed is, of course, applicableto the other CORBA structures (i.e., the DCD structure 320 and the DMDstructure 322), as will appreciated by those of skill in the art.

Referring now to FIGS. 5-7, 9A, 9B, and 11, per “step 1” of FIG. 9A, theOfflinePreParsers Tool 502 of FIG. 9B (which includes, for example, theDCD, DMD, and SAD PreParsers 208 a, 208 b, 208 c) sends a message,preParseFile( ) to the CF_PreParsers::SoftwareAssemblyParser 312 toParse XML files using existing CORBA PreParsers interface (step 710 ofFIG. 11) that is on top of the COTS XML Parser, including parsing allSAD, SPDs, SCDs, and Properties SCA XML files. To accomplish this, theCF_PreParsers::SoftwareAssemblyParser 312 sends a call,parseSCA_XMLFile( ) to the COTS XML Parser 106 (e.g., step 2 of FIG. 9A,step 720 of FIG. 11). All SAD, SPDs, ADD, SCD, and Properties SCA XMLfiles 214 are parsed (step 3 of FIG. 9A).

The parsed XML data is received (step 730 of FIG. 11) at theCF_PreParsers CORBA Interfaces (i.e., the interfaces in the UML diagram500 of FIG. 9B). The information from the parsed XML data iscollapsed/converted into a new CORBA parser structure type (step 740),such as a SAD, DCD, and/or DMD structure (step 750), as was discussedabove in connection with FIG. 6. The information used to form up theCORBA CF_Parsers structure (which by way of example in FIG. 9B is a SADstructure) is shown in FIG. 9B next to the corresponding UML note (e.g.,id( ) name( ) partitions( ) etc.), as was discussed previously above.

Still referring to FIGS. 5-7. 9A, 9B, and 11, and particularly to FIGS.9B and 11, the CORBA parser structure type is converted into a CORBA_Anytype (step 760), using the generated Any operator that the compilergenerates. As is known in the art, a CORBA Any is a container type thatcan represent any possible basic or constructed type. For example, asshown in FIG. 9B, the Offline PreParsers Tool 502 uses the <<=Anyinsertion operation to insert the SAD into a CORBA_Any. A CORBA encodeoperation is done to convert the CORBA_Any into an octet sequence (step780), using a CODEC 504 obtained (step 770) from a call to the CORBACODEC FACTORY 212 (step 765). For example, in FIG. 9B, theOfflinePreParsers Tool 508 sends calls create_codec( ) to the CORBACodec Factory 212 and encode( ) to the CODEC 504 to encode the Any intoan octet sequence. Note that each CORBA structure has two CORBA Anyoperators generated by the IDL compiler for extracting from an Any andplacing into an Any. Referring again to FIGS. 5-7. 9A, 9B, and 11, theCORBA encoded octet sequence is written to File 506 (step 5 of FIG. 9A,step 790 of FIG. 11), such as via the Offline PreParsers Tool 502sending a write( ) call to File 506. The File 506 is, advantageously, inthe form of a CORBA encoded data (CDR) file 206. As noted above, thisfile is accessible to the Embedded CF_Parsers 110.

Referring now to FIGS. 5-7, 10A, 10B, and 12, (the Optimized CF_Parsers(also referred to as Embedded CF_Parsers) Install ApplicationIllustration), a call is made (step 1 of FIG. 10A, step 800 of FIG. 12)to the optimized CF_Parsers 110A to parse the encoded CORBA file (i.e.,the octet sequence written to file in step 790 of FIG. 11). For example,referring to FIG. 10B, this is accomplished, in one embodiment by theSCA CF Domain Manager 602 sending a call parseFile( ) to theCF_Parsers::SoftwareAssemblyParser 312, then theCF:Parsers::SoftwareAssemblyParser sending an open( ) call to the File506. The octet sequence is read in (step 2 of FIG. 10A, step 810 of FIG.12), such as via the CF_Parsers::SoftwareAssemblyParser 312 sending aread( ) call to the File 508. A call is made to the CODEC factory 212 toretrieve a CODEC 504 (steps 820, 830 of FIG. 12), such as via theCF_Parsers:SoftwareAssemblyParser 312 parseFile 602 sending acreate_codec( ) call to the CORBA CODEC Factory 212. The octet sequenceis decoded, advantageously using the CODEC 504, to form the CORBA Any(step 840). For example, this can be accomplished by theCF_Parsers:SoftwareAssemblyParser 602 parseFile sending a decode( ) callto the CODEC 504.

The CORBA Any operator is used to convert the CORBA Any into a CORBACF_Parsers structure type (step 850). For example, this can be done bythe CF_Parsers::SoftwareAssemblyParser 802 calling the Any extractionoperation on the CF_Parsers::SAD 318, to extract a given structure type(e.g., SAD structure 318) from the CORBA_Any. The information from theoptimized CORBA CF_Parsers Interfaces is then retrieved (step 860), suchas id( ) name( ) partitions( ) etc.

Thus, as shown and described in FIGS. 4-12 herein, through the use ofCORBA local interfaces, CORBA encoding for CORBA deployment types (SAD,DCD, DMD) and the removal of XML parser, as described herein, moreefficient operation can be achieved. Further, as shown and describedabove, the CORBA CODEC mechanisms are used to implement and SCA systemin which, effectively, a CORBA parser replaces the XML parser. Theinventors propose that using a CORBA parser to replace the XML parser,as is shown herein for the SCA embodiments, provides significantimprovements to any systems where XML parsing is used, including but notlimited to SDR systems like the SCA SDR. For example, it is proposedthat use of a CORBA parser, as described herein, reduces code size,improves parsing speed, and requires less processing overall.

As those skilled in the art will recognize, the various embodimentsinvention described herein can be modified to accommodate and/or complywith any many different technologies and standards, includingparticularly future SCA standards, including but not limited to SCANext. In addition, variations, modifications, and other implementationsof what is described herein can occur to those of ordinary skill in theart without departing from the spirit and the scope of the invention asclaimed. Further, virtually any aspect of the embodiments of theinvention described herein can be implemented using software, hardware,or in a combination of hardware and software.

It should be understood that, in the Figures of this application, insome instances, a plurality of system elements or method steps may beshown as illustrative of a particular system element, and a singlesystem element or method step may be shown as illustrative of aplurality of a particular systems elements or method steps. It should beunderstood that showing a plurality of a particular element or step isnot intended to imply that a system or method implemented in accordancewith the invention must comprise more than one of that element or step,nor is it intended by illustrating a single element or step that theinvention is limited to embodiments having only a single one of thatrespective elements or steps. In addition, the total number of elementsor steps shown for a particular system element or method is not intendedto be limiting; those skilled in the art will recognize that the numberof a particular system element or method steps can, in some instances,be selected to accommodate the particular user needs.

It should also be appreciated that the UML diagrams, block diagrams, andflow charts provided herein do not depict the syntax of any particularprogramming language (although in some instances methods from C++, CORBAIDL and/or Java programming language have been provided by way ofexample). Rather, the flow diagrams and flow charts illustrate thefunctional information one of ordinary skill in the art requires tofabricate circuits or to generate computer software to perform theprocessing required of the particular apparatus. It should be noted thatmany routine program elements, such as initialization of loops andvariables and the use of temporary variables are not shown. It will beappreciated by those of ordinary skill in the art that unless otherwiseindicated herein, the particular sequence of steps described isillustrative only and can be varied without departing from the spiritand scope of the invention.

Those skilled in the art will appreciate that computer systems embodyingthe present invention need not include every element shown in FIG. 2,and that equivalents to each of the elements are intended to be includedwithin the spirit and scope of the invention. For example, the computersystem 50 need not include the tape drive 28, and may include othertypes of drives, such as compact disk read-only memory (CD-ROM) drives,universal serial bus (USB) drives, and any other type of removable mediaonto which information can be stored. CD-ROM drives can, for example, beused to store some or all of the databases described herein.

Systems and methods in accordance with the invention can be implementedusing any type of computer system running any one or more types ofoperating systems (including, by way of illustration and not limitation,the target embedded environment 202 and Linux Offline environment 204,described further herein). Exemplary types of computer systems on whichat least some embodiments of the invention can be embodied include anysystem or device having a processor (or equivalent processingfunctionality) installed or embedded, including but not limited to adesktop computer, personal computer (PC), laptop computer, notebookcomputer, tablet computer, handheld computer, netbook, personal digitaldevice (including but not limited to personal digital assistant (PDA),mobile communications device (including but not limited to radio,conventional telephone, mobile/cellular telephone, smart phone, musicplaying device, electronic reading device) server, workstation, andinterconnected group of computers, as well as any other type of devicehaving a microprocessor installed or embedded thereto, such as afield-programmable gate array (FPGA).

In at least one embodiment of the invention, one or more computerprograms, such as those further described herein, define the operationalcapabilities of the computer system 50. These programs can be loadedinto the computer system 50 in many ways, such as via the hard diskdrive 64, the floppy disk drive 66, the tape drive 28, a CD-ROM drive, aUSB drive, or via the network interface 58 (e.g., wirelessly, via theInternet, etc.) Alternatively, the programs can reside in a permanentmemory portion (e.g., a read-only-memory (ROM)) chip) of the main memory54. In another embodiment, the computer system 50 can include speciallydesigned, dedicated, hard-wired electronic circuits that perform allfunctions described herein without the need for methods from computerprograms.

In at least one embodiment of the present invention, the computer system50 is networked to other devices, such as in a client-server orpeer-to-peer system. The computer system 50 can, for example, be aclient system, a server system, or a peer system. In one embodiment, theinvention is implemented at the server side and receives and responds torequests from a client, such as a reader application running on a usercomputer. The computer system can be implemented as part of,controlling, or in operable communication with a terminal, personalcomputer, mainframe computer, workstation, hand-held device, electronicbook, personal digital assistant, peripheral device, notebook computer,a handheld computing device (e.g., a PDA), an Internet appliance, atelephone, an electronic reader device, an SDR, or any other such deviceconnectable to the computer network.

In addition, software embodying the present invention, in oneembodiment, resides in an application or other program running on thecomputer system 50. In at least one embodiment, the present invention isembodied in a computer-readable program medium usable with thegeneral-purpose computer system 50. In at least one embodiment, thepresent invention is embodied in a data structure stored on a computeror a computer-readable program medium. In addition, in one embodiment,the present invention is embodied in a transmission medium, such as oneor more carrier wave signals transmitted between the computer system 50and another entity, such as another computer system, a server, awireless network, etc. The present invention also, in an embodiment, isembodied in an application programming interface (API) or a userinterface. In addition, the present invention, in one embodiment, isembodied in a data structure.

Further, in describing the embodiments of the invention illustrated inthe figures, specific terminology is used for the sake of clarity.However, the invention is not limited to the specific terms so selected,and each specific term at least includes all technical and functionalequivalents that operate in a similar manner to accomplish a similarpurpose.

The invention claimed is:
 1. A preparser tool for converting SoftwareCommunications Architecture (SCA) eXtensible Markup Language (XML) filesinto Common Object Resource Broker Architecture (CORBA) structuresusable by an SCA Core Framework (CF), the preparser tool stored on anontransitory computer-readable storage medium and configured to operateon a processor remote from the SCA CF, the preparser tool comprising: acore framework (CF)_PreParsers interface definition language (IDL)configured to be in operable communication with an XML parser and withat least a first type of preparser; a first type of preparser inoperable communication with the CF_PreParsers IDL, the first type ofpreparser associated with a first type of descriptor for the CF, thefirst type of preparser configured to: call the XML parser to requestparsing of a first set of first XML files, the first set of first XMLfiles comprising a first descriptor XML file corresponding to the firsttype of descriptor and further comprising associated software packagedescriptors (SPDs), software component descriptors (SCDs), andProperties Descriptors XML files that are associated with the first typeof descriptor, as well as a first predetermined set of additionaldescriptor XML files that are specifically associated with the firsttype of descriptor; convert the first parsed set of first XML files intoa first CORBA structure having a first structure type corresponding tothe first type of descriptor, the first respective CORBA structure typebased at least in part on at least one predetermined type associatedwith the SCA CF; encode the first CORBA structure type into a firstCORBA Common Data Representation (CDR) file; and write the first CORBACDR to file as a first octet sequence.
 2. The preparser tool of claim 1,wherein, within the first set of XML files, the first type of descriptorXML file is parsed prior to parsing any of the SPDs, SCDs, andProperties Descriptor XML files.
 3. The preparser tool of claim 1,wherein the CF_PreParsers IDL and the first type of preparser areconfigured to operate using the same parser types as are used in the SCACF.
 4. The preparser tool of claim 1, wherein the first type ofpreparser is further configured to: condense the first parsed set offirst XML files so as to remove from the parsed set of XML filessubstantially all elements or operations that are not required fordeployment in the CF; and convert the condensed first parsed set offirst XML files, such that the resulting first CORBA structure typecontains only elements required for deployment in the SCA CF.
 5. Thepreparser tool of claim 4, wherein the predetermined values types andpredetermined precedence order correspond to values types and precedenceorder defined in at least one specification associated with the SCAsystem.
 6. The preparser tool of claim 4, wherein the predeterminedprecedence order comprises configure properties, executable properties,resource factory properties, and options properties.
 7. The preparsertool of claim 4, wherein the first CORBA structure type comprises asoftware assembly descriptor (SAD) CORBA structure, and wherein theelements required for deployment in the SCA CF comprise CORBA elementsthat comprise at least one of: an identifier element, a name element, apartitions element, an assembly controller identifier element, aconnections element, an external ports element, and a deploymentpreferences element.
 8. The preparser tool of claim 4, wherein the firstCORBA structure type comprises a DCD CORBA structure, and wherein theelements required for deployment in the SCA CF comprises CORBA elementsthat comprise at least one of: an identifier element, a name element, apartitions element, a connections element.
 9. The preparser tool ofclaim 4, wherein the first CORBA structure type comprises a DMD CORBAstructure, and wherein the elements required for deployment in the SCACF comprises CORBA elements that comprise at least one of: an identifierelement, a properties element, a services element, a channels element,and a name element.
 10. The preparser tool of claim 9, wherein thepreparser tool is further configured to produce a CORBA Common DataRepresentation (CDR) file capable of being installed in the SCA CF andwherein the SCA CF is configured to: acquire the first encoded filegenerated by the preparser tool; decode the first CORBA octet sequencein the first encoded file to form a second CORBA Any type, the secondCORBA Any type corresponding to the first CORBA Any type; and convertthe second CORBA Any type back into the first CORBA structure type, thefirst CORBA structure type being usable by the SCA CF.
 11. The preparsertool of claim 1 wherein the first type of preparser is furtherconfigured to convert the first parsed set of first XML files into thefirst CORBA structure type such that the component instance propertiesare converted in accordance with predetermined values types andprecedence order, the predetermined values types and predeterminedprecedence order selected to ensure that the first CORBA structurerequires substantially no further conversion for it to be used in an SCACF system.
 12. The preparser tool of claim 1, wherein the first type ofdescriptor comprises a software assembly descriptor (SAD) and whereinthe first predetermined set of additional descriptor XML files comprisesan application deployment descriptor (ADD).
 13. The preparser tool ofclaim 1, wherein first type of descriptor comprises a deviceconfiguration descriptor (DCD) and wherein the first predetermined setof set of additional descriptor XML files comprises a device packagedescriptor (DPD).
 14. The preparser tool of claim 1, wherein first typeof descriptor comprises a domain manager configuration descriptor (DMD)and wherein the first predetermined set of set of additional descriptorXML files comprises a deployment platform descriptor (PDD).
 15. Thepreparser tool of claim 1, wherein the CF_PreParsers IDL is implementedon top of XML.
 16. The preparser tool of claim 1, wherein the first typeof preparser is further configured to: convert the first CORBA structuretype into a corresponding first CORBA Any type; encode the first CORBAAny type into a first CORBA octet sequence; and write the first CORBAoctet sequence to a first encoded file.
 17. A preparsers tool forconverting Software Communications Architecture (SCA) eXtensible MarkupLanguage (XML) files into Common Object Resource Broker Architecture(CORBA) structures usable by an SCA Core Framework (CF), the preparserstool stored on a nontransitory computer-readable storage medium andconfigured to operate on a processor remote from the SCA CF, thepreparsers tool comprising: a core framework (CF)_PreParsers interfacedefinition language (IDL) configured to be in operable communicationwith an XML parser and with at least a first type of preparser; and aset of preparsers in operable communication with the CF_PreParsers IDL,the set of preparsers comprising a Software Assembly Descriptor (SAD)preparser, a Domain Manager Configuration Descriptor (DMD) preparser,and a Device Configuration Descriptor (DCD) preparser, wherein: the SADpreparser is configured to: call the XML parser to request parsing of aset of SAD XML files, the set of SAD XML files comprising at least oneSAD, at least one Application Deployment Descriptor (ADD), at least oneSoftware Package Descriptor (SPD), at least one Software ComponentDescriptor (SCD), and at least one Properties Descriptor (PRF); convertthe parsed set of SAD XML files into a respective SAD CORBA structuretype; encode the SAD CORBA structure type into a SAD CORBA Common DataRepresentation (CDR) file; and write the SAD CORBA CDR file as a SADoctet sequence; and wherein the DMD preparser is configured to: call theXML parser to request parsing of a set of DMD XML files, the set of DMDXML files comprising a DMD, an Deployment Platform Descriptor (PDD), arespective a SPD for the DMD, a respective SCD for the DMD, and arespective Properties Descriptor for the DMD; convert the parsed set ofDMD XML files into a respective DMD CORBA structure type; encode the DMDCORBA structure type into a DMD CORBA CDR file; and write the DMD CORBACDR file as a DMD octet sequence; and wherein the DCD preparser isconfigured to: call the XML parser to request parsing of a set of DCDXML files, the set of DCD XML files comprising a DCD, a Device PackageDescriptor (DPD), a respective SPD for the DCD, a respective SCD for theDCD, and a respective Properties Descriptor for the DCD; convert theparsed set of DCD XML files into a respective DCD CORBA structure type;encode the DCD CORBA structure type into a DCD CORBA Common DataRepresentation (CDR) file; and write the DCD CORBA CDR file as a DCDoctet sequence.
 18. The preparsers tool of claim 17, wherein thepreparsers tool is further configured to: condense each respective SAD,DMD and DCD set of parsed XML files so as to retain in each parsed setof XML files only elements or operations that are required fordeployment in the CF; and convert each respective condensed SAD, DMD,and DCD parsed set of XML files, such that each respective resultingSAD, DMD, and DCD CORBA structure type is substantially free of elementsthat are not required for deployment in the SCA CF.
 19. A SoftwareCommunications Architecture (SCA) Domain Profile usable by a SoftwareCommunications Architecture (SCA) Core Framework (CF), the SCA DomainProfile stored on a nontransitory computer-readable storage medium andconfigured to operate on a processor, the SCA Domain Profile comprising:a set of SCA eXtensible Markup Language (XML) files and correspondingCommon Object Resource Broker Architecture (CORBA) encoded Common DataRepresentation (CDR) data files, the set of CORBA CDR data filescomprising a Software Assembly Descriptor (SAD) CDR data file, a DomainManager Configuration Descriptor (DMD) CDR data file and a DeviceConfiguration Descriptor (DCD) CDR data file, wherein each respectiveCDR data file corresponds to a respective set of preparsed SAD, DMD, andDCD XML files, wherein each respective set of preparsed SAD, DMD, andDCD XML files is further configured to be substantially free of elementsor operations that are not required for deployment in the CF; aCF_Parsers module in operable communication with the set of CORBAencoded data files and with a client, the CF_Parsers module configuredto convert, upon receiving a request from the client, each respectiveSAD, DMD, and DCD CDR data file to a corresponding respective SAD, DMD,and DCD CORBA structure type that is usable in the CF.
 20. The SCAdomain profile of claim 19, wherein the CF_Parsers module furthercomprises a selectable local interface, the selectable local interfaceconfigured to: be selectable, at the time of compiling, to operate in alocal operational mode when the CF_Parsers module and the client are ineither the same operating system process or the same operating systempartition; and be selectable, at the time of compiling, to operate in aremote distributive operational mode in one of the following twosituations: (a) when the CF_Parsers module and the client are indifferent operating system processes from each other; and (b) when theCF_Parsers module and the client are in different operating systempartitions from each other.